1.4.3 テストの分析と設計
テストの分析と設計
例えば
要件
ソフトウェア完全性レベル（リスクレベル）
リスク解析レポート
アーキテクチャ
設計
インターフェース仕様
テストベースには会議の議事録、ホワイトボードのメモ、slackとかも含まれる 例えばUIUXの評価
評価を可能にする基準、「ものさし」が用意できるか。できなければ自ら用意できるか
アルゴリズムや中間データ
UIでの確認が難しい
結果を確認するためのメカニズムを組み込む
テストの効果や効率という意味でも重要
テストで検証すべき条件、要件を明らかにする
スケジュール面の制約
技術者の資格条件
ソフトウェア構造の分析
条件が明らかになったら目的に沿うようにテスト条件の優先順位をつける
高度なテストケース = 抽象度の高いテストケース
網羅性
要件や仕様に対するカバレッジ
コードカバレッジ
ユーザー指向
利用する視点
要件指向
要件の妥当性を見る
フォールト指向
欠陥を見つけるため
設計指向
設計通りにテスト対象が動作するか
テスト実施に必要な環境
物理的側面
開発環境とテスト環境を分離するか
OS、ミドルウェアのバージョン、バンドルするアプリの種類
プロトタイプ→試作機→量産試作機→実機
論理的側面
ミドルウェア、ファームウェアの可変パラメータのデフォルト値
テーブル設計の組み合わせ
テストドライバやテストツールでの実施
コスパの問題
テストの有効性を損なわないような代替項目の検討
テストの必要性の有無の検討
トレーサビリティ = 追跡可能性
確保できていれば、テストベースに変更あってもテストケースのどこを直せばいいかがわかる
トレーサビリティの確保に使えるもの
トレーサビリティマトリックスの作成
要求管理ツール
ALM(Application Lifecycle Management)ツール